You can suppress the warning with dotnet_diagnostic.CA1416.severity = none but imao if you only intend to use it on Windows you should set Target OS to Windows for the project which will fix the warning.

https://docs.microsoft.com/en-us/dotnet/core/compatibility/code-analysis/5.0/ca1416-platform-compatibility-analyzer

Source:

https://stackoverflow.com/a/70272543/3850405

Similar to what @RonC did, I was able to solve the problem by adding a Rule to my .ruleset file:

<Rules AnalyzerId="Microsoft.Analyzers.ManagedCodeAnalysis" RuleNamespace="Microsoft.Rules.Managed">  
  <Rule Id="CA1416" Action="None"/>
</Rules>  

Just keep in mind that this will apply to the whole project for which the ruleset file is used.

One way to solve this issue is to create an .editorconfig for the solution and then add the following line to that .editorconfig file:

dotnet_diagnostic.CA1416.severity = none

This will make all "Validate platform compatibility" warnings go away.

I had success removing the CA1416 warnings by adding the following decorator to the top of the containing class:

[System.Runtime.Versioning.SupportedOSPlatform("windows")]

I'm only on VS2019 and using .net 5, but it may work for you. I tried this with VS2019 .net5 console project (top of class Program) and a .net5 class library (top of the class). I added the System.Common.Drawing nuget package. My code included:

string inputPath = @"C:\mypath\mypng.png";
Image i = Image.FromFile(inputPath);

Hi, although this article does not yet solve my version of the problem - selectively running Windows-specific code based on whether I am on Windows or not,

I at least have the direct solution for your AssemblyInfo.cs:
Just take a look at the autogenerated version in <your project name>\obj\Debug\net6.0-windows\<your project name>.AssemblyInfo.cs

It uses the exact same mentioned SupportedOSPlatform Attribute, together with another one above it (I don't know it's exact effect yet), in the following way:

[assembly: System.Runtime.Versioning.TargetPlatformAttribute("Windows7.0")]
[assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute("Windows7.0")]

So you can add these to your own custom AssemblyInfo.c.s file if you like (though of course in a manually written code, I would prefer to place the System.Runtime.Version namespace with a using statement on top of the file and I would also remove the "Attribute" suffix to make the name shorter, and my personal choice is to omit the "7.0" if I am not 100% certain about whether my code really still works on Windows 7).

In my opinion an approach this is always better then simply suppressing warnings. Because otherwise you're choosing a work-around rather than serving a solution.

One small note though:
This whole problem has nothing to do with "Visual Studio 2022", but with the way how .NET itself works, and with the C# compiler that gives the warnings.

Ah, I also found the answer to my own question now: selectively running code.

//using System.Runtime.InteropServices;

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    // Do some Windows-only stuff.
}

I needed this because of certain code that I cannot use on Linux (and also don't seem to need).

The amazing thing here is: everything placed inside this condition no longer generates the CA1416 compiler warnings.

So somehow they clearly did some very special C# compiler stuff there to make this code recognized correctly in the way you want.

Update: Turns out the above code is already kind of obsolete, there is a newer way starting from .NET 5 that you actually should use for selectively running code: System.OperatingSystem.IsOSName(). Here the updated example:

//using System;

if (OperatingSystem.IsWindows())
{
    // Do some Windows-only stuff.
}

The story about not getting warnings anymore, etc is the same by the way.

I really want to express that one of the most frustrating problems of searching for things on the internet is that really too often you find many very old answers rather than the updated one that you actually need.

And to make things worse, the Microsoft docs that I have found are totally unclear about which thing to actually use (I only find API reference docs, but no tutorial kind of docs), or the right docs are just so incredibly difficult to find that I did not succeed in finding them.

It's really certain comments in the issues on the github dotnet repos that gives you the right suggestion about the right/best way of doing things.

I deeply recommend anyone finding this page to do their own investigation, especially if you're reading this many years later. It would not surprise me that my answer here is very quickly going to be very obsolete as well. 😒